Today's relational databases can be organized in a couple of ways. For example, relational databases can be organized where entities and properties are stored as tuples (rows or records) and attributes (columns or fields) of entity tables, and relationships between entities are stored as tuples in relationship tables. Also, another type of relational database is organized where tuples are holding relationship triplets.
A table of tuples can record many attributes in a row of cells. But these tuples are notoriously inefficient. The tuples are inefficient because each row of the table must have the same number and type of cells. In other words, the longest row determines the size of the table, which leads to many empty cells in other rows. As a result, the tuples consume a large amount of computer memory, and tax the processing power of the computer. Splitting the table can be used to lessen the number of empty cells, but at the cost of increased software complexity. For example, and referring generally to FIG. 1A, there can be a “people” table 101 and an “automaker” table 102. Properties of people and automaker entities are stored as attributes in the tuple. A “favorite” relationship table 103 records in tuples that a particular “person” entity is related to an “automaker” entity by the implied “favorite” relationship. So a relationship is recorded that a person has a favorite automaker.
A table of relationship triplets is more flexible than standard tuple storage of separate relationship tables. The triplets are stored in tables each having two columns for recording entities and one column for recording relationship types. These entities are recorded in entity tables, in which each entity table may be of a certain type. The relationship types are recorded in a relationship type table. For example, and as before, referring generally to FIG. 1A, there can be a “people” table 101 and an “automaker” table 102. Instead of the “favorite” relationship table 103, there is a “relationship triplet” table 105. This triplet table records in tuples that a primary entity is related to a secondary entity by the explicit relationship type, defined in the relationship type table 104. So a relationship is recorded that a person has a favorite automaker, or that a person owns a car made by an automaker. Again, properties of people and automaker entities are stored as attributes in the tuple. This makes it difficult to combine the entity tables to allow the capability to record that an automaker has a favorite automaker, or that a person has a favorite person.
The relationship tables each typically have constraints that limit which types of entities are eligible to be placed in which column. For example, the “favorite” table 103 can have constraints that cause an exception to be thrown if a process attempts to place any entity not from the “person” table 100 in its leftmost column. Similarly, the “favorite” table 103 can have constraints that cause an exception to be thrown if a process attempts to place any entity that is not from the “automaker” table 102 in its rightmost column. Accordingly, the “favorite” table 103 would not record that an automaker has a favorite person, a person has a favorite person, or an automaker has a favorite automaker. On the other hand, if it is desirable to allow a relationship to be recorded that a person has a favorite person, the constraints can permit this type of relationship to be recorded. Similarly, the relationship triplet table 105 has the same constraint situation.
An index and retrieval system of a typical relational database searches the database contents employing a number of different operators that perform relational algebra. In a simple example, the index and retrieval system searches for all incidences of a queried entity or relationship. For example, a search query consisting of the name of a certain person returns every triplet containing that person and reports the entities in each column and the relationship in a “semantic” fashion. In other words, if a query asks for “John,” then a search of the triplet table 105 is performed for every triplet containing the search term, thus obtaining results reporting that “John favors FIAT™.” Similarly, a query that asks for “FIAT™” causes a search of the triplet table 105 for every triplet containing the search term, thus obtaining results reporting that “FIAT™ is favored by John,” and “FIAT™ is favored by Paul.” The active or passive voice can be used to communicate the column in which each entity was found. Further, a query that asks for the relationship, “favorite,” causes search of the triplet table 105 and obtains results reporting that “John favors FIAT™,” “Paul favors FIAT™,” “George favors BMW™,” and “Ringo favors LAMBORGHINI™.”
Relational databases have proven useful, leading to the development of many relational database implementations of custom design. In the past, each type of entity and each type of relationship has been defined in advance of use of the relational database. When it becomes necessary to define another type of entity or relationship, the databases have to be entirely reconstructed. Much effort has gone into attempting to automate, as much as possible, the process of deconstructing the legacy database 106 and porting the data into a new database that has the new characteristics. Much work has also gone into attempting to automate the construction of a relational database by mining data and constructing the relational database by observing semantics of the data and trying to instantiate the relationship based on the semantics. But there is still no way to dynamically extend the capabilities of a relational database without having to reconstruct the database.
The difficulty in solving the aforementioned problem stems from limitations that have been prohibitive. The difficulties are:                Tables that hold “triplets” of Entity-Relation-Entity are efficient for representing relations, but the model does not fit enough of the subtleties of data definition to define other data constructs.        Spreadsheet-style tables contain rows with many empty columns.        Multi-dimensional information is highly variable and usually requires custom tables.The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.        